Introduction to XML

Polishing the First Draft

Your first attempt at writing a computer program larger than a few lines will always be flawed. Not just bugs, but also inefficiencies, redundancies, and things that might annoy, mislead, or trip up the user.

So you'll always want to put your program through its paces. Use it for a while, noting anything you should improve. And if you have a few willing friends, ask them to test it too.

Here are the six shortcomings that I found when trying out this first draft of the Quiz Data Entry program:

Now close VB. We're finished looking at the first draft of the data entry program.

In Windows File Explorer, open the C:\XML 11 Finished\Quiz Data Entry Improved Final folder. Click the Quiz Data Entry.sln file to reopen VB with the polished, final version of this program. Now you can follow along and view the modified, improved code where I've fixed the six shortcomings listed above.

Fixing Form_Load

When users start our program, they either want to begin creating a new quiz or append questions to an existing quiz. In Form_Load, we should explain how to accomplish these goals if a quiz.xml file already exists. So make the following highlighted changes to Form_Load:

Adding Data Validation

Now, our second fix is to validate the data. People enter typos, get tired or mixed up, or otherwise type in bad data. You don't want to mess up your XML file with empty elements, answers where there should be questions, and so on.

So you should assume that there will be errors during data entry. Have your program validate the data—and if it finds a problem, it should display a message box explaining what's wrong and how the user can fix it.

Let's get started adding some validation code. We need to fix two potential problem areas in our program:

• Does the answer textbox contain only a t or an f? We can't permit any other input, because the Quiz program we'll write later in this lesson will be looking for a t or f answer only.

• When the user presses the TAB key to move out of the answer textbox (to move to the next empty form), does the question textbox contain a question, or is it empty? If it's empty, we need to tell the user to type a question.

What event should we use to add our validation code? Not surprisingly, the best textbox event to use for validation is the Validating event! And we want to validate just before saving the Q/A pair and moving on to a new, blank form. This happens when the user has just finished typing into the txtAnswer textbox (and pressed the TAB key). So we'll put our validating code in the txtAnswer_Validating event.

1. Double-click form1.vb in the Solution explorer.
2. Now, double-click the form and locate the txtAnswer_Validating event in the Code window.

Most of this code is easy to understand. The user has just pressed the TAB key, triggering this Validating event. This trigger fires, because those who wrote VB understand data entry, so they know that validation should happen right after a TAB key is pressed.

We test to see if there's a t or f in the textbox—and if so, execute a sub called SaveQA (we'll add that sub in a minute). But if t or f is not in the textbox, the data is invalid and the e.cancel  command keeps the focus in the txtAnswer textbox (in other words, the TAB key is ignored, and we stay right where we were). Then we tell the user the problem and empty the txtAnswer textbox, so the user can type in the required t or f.

Now we need to create a new sub we'll call SaveQA. It will append the current Q/A pair to the Quiz.xml file (a job previously done by the KeyDown event). The reason for putting this code in a separate, new sub (rather than in an existing event) is that two different events will need to save the Q/A pair. So rather than duplicating this code in those two events, we'll just have the events execute in a new custom SaveQA sub we create.

3. Locate Sub SaveQA in the code window.

I deleted the entire KeyDown event from the earlier version of this program. We won't use it anymore. KeyDown was where we checked to see if the user pressed the ENTER key. But from now on, we'll let VB trigger the txtAnswer textbox's Validating event when a TAB happens.

Validating That No Fields Are Empty

We also want to validate that when the user presses the TAB key both textboxes contain text. This is when our code saves the Q/A pair. By insisting on t or f, we've already ensured that the txtAnswser field has the right content. So now all we need to do is make sure that the txtQuestion field isn't empty. Recall that in VB "" (empty double quotes) means "no text."

I changed the first line in the txtAnswer_Validating event to add this new condition:

What we're saying here is that txtQuestion field must not be empty (<> means not-equal-to). So it says, "not equal to empty."

Did you notice that I put parentheses around the two Or conditions here? That tells VB to check this Or condition before checking the And condition.

Does it matter which conditions VB analyzes first? It certainly does. This complex condition can mean two entirely different things.

Consider this similar real-world, three-condition statement:

If you're driving in a terrible rain storm or you're feeling tired and you're in no hurry, then it's best to check into a motel.

This sentence can be interpreted two different ways:

Avoiding Typing True or False

This fix is simple. In the first draft of the data entry program, we had a label next to the Answer textbox that told the user to type True or False (T or F). That's clumsy in two ways. Users shouldn't have to keep typing the whole words True and False. They should just type T and F. What's more, they don't need to capitalize these letters either. Stick with lowercase t and f. (Anything to make the data entry more efficient.)

How do we change this? Just change the label on the form to read: Type in t or f. (But as you'll see shortly, we'll get rid of this label completely and move these instructions up to the form's title bar.)

Ensure We're Saving All Elements

As it stands, our Exit button is dangerous. The only code in it is the End command. So what will happen if the user finishes typing in a question and answer, but then clicks the Exit button? The program will end without saving that final Q/A pair that the user just typed in.

Clearly this is a bug we need to fix. We need to put some code in the btnExit_Click event that checks to see if the two textboxes contain text. And if they do, we must save this final Q/A pair element to the quiz.xml file.

I added this code to the btnExit_Click event to accomplish these goals:

Translation: End the program if either of the text fields are blank. I figured that the user wouldn't accidentally click the Exit button. In other words, if either field is empty, the user wants to throw away this Q/A pair, so I end the program. But if neither field is empty, then save the Q/A pair before ending the program.

Fixing an Ugly UI

In the first draft of the data entry program we had another boring default gray interface. But you now know how to improve the UI on your own after learning how to use the BackgroundImage and other properties in previous lessons. In addition to adding some graphics to the form's background and exit button, I removed the labels and just put their instructions up in the form's title bar.

People generally fall into two camps when it comes to their design preference—clean or complicated. The technical terms for this difference in styles are modern or Baroque. The former is simplified and clean but can also be severe, and the latter is complex and ornate, although sometimes cluttered. Think of a modern square glass box building versus a Renaissance Italian church.

Both styles can be good, but I mostly lean toward Baroque, as you probably already suspect from the way I added all that gold texture to the cookbook program in a previous lesson. But choose the style you like.

Here's one of my favorite UI tricks: Do your background in a graphics program. They have hundreds of tools, textures, and other options:

1. Take a screenshot of the UI (run your program, and then press ALT + PrtScn to capture the form).
2. Paste the UI into a graphics editor like Photoshop.
3. Crop off the form's frame, a title bar, so just the actual BackGroundImage is showing.
4. Fill the background with textures, gradients, images, whatever you like.
5. Add drop shadows around the buttons.
6. Once you've finished making the UI look great, save the file, and import it into your program as the BackGroundImage of the form.

Notice that I got rid of the labels and put their instructions into the form's Text property.

Great work! All right, take a break, and then meet me in Chapter 4 where we'll create a program that gives a quiz.

Creating a Quiz

Now, let's look at the companion program to the Quiz Data Entry project. Called simply Quiz, this program consumes (programmer-talk for uses) the data created by the data entry program that was stored in the quiz.xml file. And that data is the quiz questions.

Go ahead and open the quiz program by double-clicking the quiz.sln file in your C:\XML L11 Finished\Quiz folder.

It's surprisingly easy to write this program. It requires very little code if we keep things simple. As always, start by listing the tasks the program needs to do:

Normally, the second step when writing a VB program is to build the UI—you add whatever controls are required to do the jobs listed in the first step.

But because we're keeping this program very uncomplicated, we won't even use controls. We won't display a form. We'll just ask the true/false quiz questions by displaying a series of message boxes.

So far in this course, we've worked with only the most basic type of message box—one that presents some text to the user, along with an OK button that dismisses the message box if the user clicks it. But message boxes come in several styles. For example, a message box can accept yes or no input from the user, like this:

Let's see how it works.

As always, the housekeeping code goes into the Form_Load event, because that event automatically executes when the program first starts up.

I started with the following lines of code at the top of the Code window. This programming should be very familiar to you by now.

The Cookbook program uses this same code with the exception of the filepath and filename. To review, this is what's happening in this code:

Building the Main Loop

Many programs keep repeating something (looping) until some condition is satisfied. It's the same idea as real-world jobs like washing a car—you keep rubbing a soapy sponge on the car until it's clean.

The loop part is the rubbing, and the exit condition is that it's clean. There might be smaller, secondary loops, like hosing water into the bucket until it's full, and wringing the sponge until it's not waterlogged. But clearly the main loop—the main action—is the rubbing.

Similarly, the main loop for our quiz is asking questions over and over. And the exit condition is running out of questions, reaching the end of the XML document.

But we want to use a larger loop, too, an outer loop that can repeat the entire quiz if the user wants to try again. And the outer loop's exit condition is the user clicking a No button, saying that they don't want to take the quiz again.